1. Field of the Invention
The present invention relates to Mobile Internet Protocol version 6 (Mobile IPv6) and more particularly to optimizing the authentication key setup and management in Mobile IPv6.
2. Description of the Related Art
Mobile IP version 4 (Mobile IPv4, Mobile IP, MIPv4 or MIP) and the current version of Mobile IPv6 (MIPv6) are built to provide mobility to a host or Mobile Node (MN). The other nodes, usually referred to as Correspondent Nodes as (CN), are usually seen as fixed hosts. Reference is now made to the drawings where FIG. 1 shows a MIPv6 network architecture as suggested by the current MIPv6 specification found in an Internet Engineering Task Force (IETF)'s Request For Comment (RFC) number 3775, herein included by reference. As can be seen in FIG. 1, an IP network 100 comprises a MN 110 in communication with a CN 120 on a link 122. The link 122 is unlikely to be composed of only one direct physical connection, but rather represents a series of links between routing equipments transparently enabling the communication therebetween. The way the series of links is used to transport traffic between the MN 110 and the CN 120 is irrelevant as long as IP communication therebetween can be established.
The MN 110 has a permanently assigned home address valid in its home network 127, which home address is allocated upon initialization of the MN 110 in the home network 127. The allocation mechanism falls outside the scope of the present invention. The MN 110 is further in communication with a Home Agent (HA) 130 located in its home network 127. Among other functionalities, the HA 130 keeps record of a foreign address of the MN 110 valid outside the home network 127. The foreign address is called Care-of-Address (CoA) in the context of MIPv6. The CoA assigned to the MN 110 changes in time as the MN 110 moves from one network to another. The record kept by the HA 130, referred to as binding in the context of MIPv6, ties the CoA to the home address. A binding between the home address and the CoA is also kept in the CN 120 for the purpose of reaching the MN 10. The HA 130 is also responsible for routing traffic received at the home address to the MN 110. The traffic received is forwarded by the HA 120 on a link 125 toward the MN 110. All traffic sent on the link 125, in accordance with MIPv6, is encrypted to ensure, among other things, confidentiality of credentials periodically exchanged between the MN 110 and the HA 130. It should be noted that the MN 110 may have multiple home addresses and multiple CoA addresses and that a binding should be kept at the HA 130 for each pair of home address-CoA.
The following lines are an example of how the MIPv6 concept applies in a typical situation. For the benefit of the example, the MN 110 is in bidirectional IP communication with the CN 120 on the link 122. When the MN 110 moves from a first network to another, as illustrated by an arrow 135 on FIG. 1, the MN 110 receives a new CoA. This modification in addressing state of the MN 110 must be advertised to the CN 120 and the HA 130. Prior to the advertisement, the MN 110 must first make sure that the home address, which did not change, is still valid and that the newly acquired CoA address is usable to communicate with the CN 120. This assessment is done via a return routability (RR) test or procedure. The RR procedure also allows the creation of an authentication key. For this purpose, a Care-of init cookie and a home init cookie are built by the MN 110, also protecting the RR procedure from being spoofed.
The RR procedure starts at the MN 110, which sends a Home Test Init (HoTI) message through the HA 130, on the link 125, using its home address as the source address. The HoTI message contains the home test init cookie and is addressed to the CN 120. Upon reception of the HoTI message, the HA 130 forwards it to the CN 120 on a link 140. The link 140 has the same characteristics as the link 122. Simultaneously to sending the HoTI message, the MN 110 sends a Care-of Test Init (COTI) message containing the Care-of Init cookie toward the CN 120 on the link 122 with its new CoA as the source address.
Upon reception of the CoTI message, the CN 120 replies with a Care-of Test (CoT) message addressed to the source address of the CoTI message (i.e. the MN's 110 new CoA) on the link 122. The CoT message contains the Care-of Init Cookie and a care-of keygen token generated by the CN 120. Upon reception of the HoTI message, the CN 120 replies with a HoT message addressed to the source address of the HoTI message (i.e. the MN's 110 home address) on the link 140. The HoT message contains the home Init Cookie and a home keygen token generated by the CN 120. Reception of the CoT and HoT messages at the MN 110 successfully completes the RR procedure. The MN 110 keeps the content of both the HoT And CoT messages and then continues with the advertisement of the modification of its CoA toward the CN 120 and the HA 130.
In order to advertise modification to its CoA, the MN 110 sends a first Binding Update (BU) message to the HA 130 on the encrypted link 125 containing the newly acquired CoA and other information related to the HA 130 binding. The HA 130 then updates its corresponding binding and replies to the MN 110 with a first Binding Acknowledgment (BA) indicating the successful update of the binding. The MN 110, after sending the first BU, uses the care-of keygen token and the home keygen token received earlier from the CN 120 to generate an authentication key Kbm valid between the MN 110 and the CN 120 for a period of 210 seconds (3,5 minutes). The authentication key Kbm is commonly referred to as binding management key in the context of MIPv6. The MN 110 then creates a second BU similar to the first BU, signs it with the key Kbm and sends it to the CN 120 on the link 122. The CN 120, upon reception of the second BU or before, generates the same key Kbm using the tokens it already generated and further verifies the received second BU before updating its own related bindings. The CN 120 then creates a second BA, signs it using the key Kbm and sends it, in accordance with the MIPv6 specification, on the link 125 toward the HA 130, but addresses the second BA to the MN 110. The HA 130 simply forwards the second BA to the MN 110. Reception of the second BA at the MN 110 indicates the successful completion of the advertisement of the modification.
As mentioned earlier, the authentication key Kbm is only valid for 210 seconds. Therefore, the RR procedure and the exchange of BU/BA need to take place repetitively within a shorter period. The interval is set to a period of 210 seconds since the authentication key Kbm can be relatively easily retrieved, especially if the care-of keygen token and the home keygen token exchanged between the MN 110 and the CN 120 are intercepted. Once the authentication key Kbm is known, it can be used to hijack content of the communication exchanged between the two nodes. It should further be emphasized that the current key creation mechanism does not prevent interception of the care-of keygen token and the home keygen token and, thus, does not appropriately prevent deception or spoofing of the authentication key Kbm during its creation.
The prior art mechanism poses many problems. For instance, the RR procedure and the exchange of BU/BA trigger a lot of signaling, which is particularly costly on the path from the MN 110 to the CN 120 that goes through the HA 130. Moreover, it is inefficient due to the short period of validity of the authentication key Kbm, especially when the MN 110 does not change its CoA (i.e. remains in the same network where CoA is valid). Unfortunately, the validity period of the authentication key Kbm cannot be increased without decreasing the level of security. Furthermore, the level of security is already low due to the weak mechanism used to obtain the authentication key Kbm.
As can be appreciated, there is a need for an efficient solution to setup and management of the authentication key used between nodes using Mobile IPv6.